home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000132_owner-urn-ietf _Thu Oct 31 06:00:11 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA11383 for urn-ietf-out; Thu, 31 Oct 1996 06:00:11 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA11378 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 06:00:09 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21426  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 06:00:00 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00655-0@josef.ifi.unizh.ch>; Thu, 31 Oct 1996 11:58:36 +0100
  7. Subject: Re: [URN] New syntax draft (was: no subject)
  8. To: jayhawk@ds.internic.net
  9. Date: Thu, 31 Oct 1996 11:58:35 +0100 (MET)
  10. Cc: internet-drafts@ietf.org, urn-ietf@bunyip.com
  11. In-Reply-To: <327762F6.3701@ds.internic.net> from "Ryan Moats" at Oct 30, 96 08:15:18 am
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 2081
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..728:31.09.96.10.58.37"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. >Internet-Draft                                                Ryan Moats
  24. >draft-ietf-urn-syntax-00.txt                                        AT&T
  25. >Expires in six months                                       October 1996
  26.  
  27.  
  28. >1.2 Namespace Specific String Syntax
  29. >
  30. >   Depending on the rules governing a namespace, valid identifiers in a
  31. >   namespace might contain characters that are reserved characters in
  32. >   URI syntax or non-printable ASCII characters.  To accommodate the
  33. >   largest set of valid identifiers, the NSS portion of a URN shall use
  34. >   UTF-8 representation of ISO 10646 as its character set.  Namespaces
  35. >   that do not currently use ISO 10646/UTF-8 are encouraged to migrate
  36. >   to it.
  37.  
  38. Very well put!
  39.  
  40. >   URN resolvers MUST be capable of accepting URNs that have been
  41. >   %encoded for either 8-bit clean or 7-bit transports.  %encoding is
  42. >   removed first, then UTF-8 decoding is performed.  URN resolvers MUST
  43. >   return identical results from ANY legally encoded form of the URN.
  44.  
  45. I wonder about UTF-8 decoding. It somehow implies that resolvers
  46. work with Unicode internally, which would be fine, but is not
  47. necessary. For database lookup and equality checks, staying with
  48. UTF-8 will also be okay. For things such as regular expressions,
  49. some additional definitions are necessary as to what the regular
  50. expressions are working on (i.e. characters or octets), but still
  51. it could work in UTF-8.
  52.  
  53. Also, what does UTF-8 decoding mean for an NSS that is not UTF-8?
  54.  
  55.  
  56. >   It should be noted that certain characters in the Namespace Specific
  57. >   String syntax may have special meaning in certain namespaces.
  58. >   Therefore, the process of registering a namespace identifier shall
  59. >   include publication of a definition of which characters have a
  60. >   special meaning and how to encode these characters if used in a
  61. >   literal sense.
  62.  
  63. Can they be encoded with %HH? Or should we specifically request some
  64. other mechanism in order to not confuse different things, and let
  65. programs that deal with URNs in general change from %HH to 8-bit
  66. and back?
  67.  
  68.  
  69. Regards,    Martin.